Many software programs or applications have the ability for the operator of the application to change the configuration of the application, the computer, the network upon which the application is running, or for the devices which the application is controlling. One way for an application to allow an operator to change a configuration, is for the application to present a secondary window to the operator displaying the data with which the present configuration is based, and giving the operator the ability to adjust this data. A secondary window which contains configuration data, and components for adjusting the configuration data, is known as a configuration form.
Network management software controls many different devices in a computer network and therefore has a large amount of data which can be configured by an operator. Each device management application within network management software provides many different configuration forms, often graphical in nature, and also referred to as dialogues and/or property sheets. These configuration forms enable users to configure the network devices from a remote location. Each configuration form displays the current value of one or more device attributes or operating parameters. The user interacts with the form to change the value of the attributes, and usually clicks a button to apply the changes to the device. The network management software then transfers the new values of the attributes to the device.
Although tools vary from platform to platform, the traditional method for developing device configuration forms includes the following steps.
The developer first researches the new device to determine the requirements for the configuration forms. This involves reviewing the Management Information Base (MIB) that the device supports and recommending changes or additions.
The developer then decides which data items (usually device MIB variables) are meaningful and useful to a user. Next, the developer determines how many configuration forms are needed and which data items should be displayed together on a single form.
For each data item the developer must decide what kind of widget or component will be used to display the data item. This decision is usually based on the properties of a data item, but often varies greatly from developer to developer. There may also be other widgets required for control (e.g. buttons) or to display/obtain data that comes from the user, not the device.
The developer then uses a tool to select the desired widgets and arrange them on the form. Although most tools provide aides to facilitate the alignment of widgets, the developer is responsible for placing each widget and associated label on the form, and aligning the widgets and labels with those in the surrounding area. The developer must create a visually appealing and intuitive layout while complying with the appropriate style guides. Creating a form with proper spacing and alignment is tedious and must be revisited each time the form changes.
Next the developer usually generates some amount of source code for the form using the tools. The amount and quality of the code varies from tool to tool, but the form almost always requires a significant amount of additional coding.
The developer must then complete the coding of the form, including retrieving the values of all data items from the device, handling user-generated events, validating the users input, and applying the users changes to the device.
The form is then integrated into the application tested for both proper operation and appearance.
Finally, the tested application is released, purchased by a customer, and installed on the customer's machine. Any change in an application will require the releasing of an updated version which is a substantial undertaking and requires significant documentation. This traditional method for providing device configuration support is problematic in many ways.
As software applications control more and more devices, and provide more functions and abilities, the number of configuration forms increases dramatically. Each improvement in an application usually adds additional configuration forms, with the result that a large number of configuration forms are developed over a number of years by different people. The result is that even within a single application, forms vary considerably in appearance, layout, alignment and widget selection. Moreover, many of these forms do not comply with the user interface style guide for the platform, and therefore fall short of a customer's expectations.
Consistency between windows UNIX and the command-line interface provided by the software embedded within a network device is virtually non-existent today. Application operators are forced to learn completely different styles to configure their application, computer or network. With Web-based configuration management, the consistency problem could potentially get worse.
Every configuration form is currently individually constructed, including both the graphical design and layout of the widgets within the form, and the code that controls the form and interacts with the device. A large amount of duplicate effort is required to develop and test these forms for all platforms (Windows, UNIX, Web, Embedded). Also, the amount of code that must be compiled and linked with each build grows with each new form, slowing down development time significantly.
Compared to other functionality provided by network management tools, configuration forms are not difficult to build. However, there are such a large number of configuration forms, that even a little wasted effort per form is expensive. Many network management applications have over 1,000 configuration forms.
The state of the art in graphical user interface (GUI) design changes rapidly. Windows 95 defined a new standard for the GUI on a Windows platform along with numerous new types of controls (widgets). Windows 97 along with advances in Web-base technologies will actually cause another major GUI paradigm shift in the near future.
Configuration forms developed in the conventional manner are compiled into executable software modules that must be then integrated, tested and installed with the entire application. New configuration forms can then only be released when a new version of the application is released.